In modern distributed applications, communicating between application services via a messaging system is an efficient and highly adopted pattern. Messaging software implementing the standard application programming interface (API) such as advanced message queuing protocol AMQP (e.g., RabbitMQ™) is widely used by business critical applications in order to transport business information asynchronously. Since the messaging has become a critical part of the dataflow in those critical applications, messaging introduced durability features allowing definition of queues as “durable” meaning that the queue contents are preserved even if the messaging software breaks and restarts. As for high availability and fault tolerance, mature messaging software offers replication between multiple nodes. While both features described above create an enterprise mature solution, there is a gap in the use case of business continuity.
Business critical applications requires being able to restore the entire application state to a previous point in time in case of data corruption, bugs or internal auditing. Messaging stores part of the application state as much as a database or any other persistent services. While two features above (e.g., high availability, durable messages) solve some of the business requirements, being able to restore the full application state is missing. Conventional systems utilize scripts for backup of messages. However, such message backups are not consistent, since the messaging software is not built with the backup use case in mind, the scripts might miss messages, acknowledgments or miss inter cluster inconsistency and failures. Since the application is consistent of multiple data services (e.g. a database, durable messages) there is no orchestration in the restore procedure to support a full restore of an application to its previous state.